All computer systems comprise a co-operating collection of devices. The central processing unit (CPU) is responsible for most compute functions. However, data must be passed onto and off of the CPU in order for the computer system to be useful to the user. Keyboard, displays, mouse, etc are all necessary peripheral equipment for the computer user to interact with the system. Initially, all these peripherals have been attached to the computer through dedicated interfaces. For example, the keyboard connects through the keyboard port, the mouse connects through the mouse port, and the display device connects through yet another dedicated port. As computer systems have evolved to provide more functionality, more peripherals have been introduced. Network connections were added to enhance interconnectivity to other computer systems. Scanning interfaces were added to allow direct input of image data. Printer interfaces add the ability to produce hard copy of the data being manipulated. Video cameras, graphics tablets, external storage devices, etc. all have contributed to a complex wiring configuration in computer systems.
To address this problem, interface bus systems have been developed. Small Computer System Interface (SCSI) was one such parallel bus. This bus system allowed high-speed connection of multiple devices to a single interface on the computer system. However, the standard did not allow for “hot-plugging,” thus requiring the computer system to be powered down for every change in peripheral device attachment configuration. The more popular Universal Serial Bus (USB) architecture was introduced in recent years. This bus allowed “hot-plugging” and automatic configuration of peripheral devices as they are added. The system of “plug-and-play” was also addressed by the USB architecture so that the appropriate device driver is launched on detection of a new peripheral device being added onto the bus.
FIG. 1 illustrates an example bus driver architecture. The USB architecture and the bus driver software on the computer's operating system together service the devices (116, 118, 120) on the bus 114. The primary responsibilities of a bus driver 112 are to enumerate the devices (116, 118, 120) on its bus 114, respond to Plug and Play (PnP) requests, respond to power management requests, multiplex access to the bus 114, and administer the devices (116, 118, 120) on the bus 114. Function drivers (106, 108, 110) are then established as the main driver for the device (116, 118, 120). A function driver (106, 108, 110) is typically written by the device vendor and is required. The PnP Manager loads at most one function driver (106, 108, 110) for a device (116, 118, 120). The same function driver (106, 108, 110) can service one or more devices (116, 118, 120). A function driver (106, 108, 110) provides the operational interface for its device (116, 118, 120). Typically, the function driver (106, 108, 110) handles reads and writes to the device (116, 118, 120) and manages device power policy.
FIG. 2 illustrates an example bus driver architecture for multi-function devices. On the Windows operating system, a multifunction device 222 is supported by defining it to occupy one device location on its bus 214, but contains more than one functional unit (216, 218). Each functional unit (216, 218) corresponds to a driver (206, 208, 210)). Examples of multifunction devices include combination modem/network adapters, combination audio/game ports, and so on. Such devices appear to the operating system as multiple separate devices. For example, an add-on sound card that implements audio and gameport capabilities appear as two independent devices, one serviced by audio drivers and the other serviced by a gameport driver.
The operating system places a restriction on these functional units (216, 218, 220). Each functional unit (216, 218, 220) must be able to operate as a separate device, even if it happens to be serviced by an instance of the same driver(s) as another functional unit on the device (222, 220). In particular, functional units on a multifunction device 222 must not have start-order dependencies, the resource requirements of one functional unit must not be expressed in terms of another functional unit, the operation of one functional unit must not affect or interfere with the operation of another functional unit on the multifunction device 222 or on the system as a whole, each functional unit must be enumerated and its resource requirements communicated to the operating system so the system can load the necessary drivers and assign resources to the different units in any order.
The above capabilities and restrictions of device attachment on a USB bus on Windows based system have been successful in serving a large number of peripheral devices. However, as computing systems evolve in sophistication, the peripheral devices are also growing in complexity and functionality. The peripheral devices are becoming self-contained computing systems that require multiple communications channels to interact with the operating system. Each of these communications channels may be used to effect different functions. For example, wireless wide area networking devices need to interact with the operating system to convey several streams or channels simultaneously for streams such as, but not limited to, a primary receive and transmit data paths, additional data channels for wireless network access using multiple contexts or separate Quality of Service data channels over the same context, a control and status channel, a diagnostics and maintenance channel, and a Location Based Services (LBS) channel running a location protocol such as the National Marine Electronics Association (NMEA) protocol. Each of these channels requires independent data transfer channels and independent driver handling. Yet these channels cannot be considered independent devices on the bus since they may have start-order dependencies. For example, the control and status data path channel might need to be started prior to any of the other channel paths in order to query the device and the network it is communicating with to determine what services the network and device are capable of before attempting to open one of the other channels that are dependent on one or more of these services.
Windows driver designers address more complex devices like the ones described in the previous paragraphs with the use of multifunction drivers for multifunction devices. A multifunction driver is a bus driver and thus has several advantages. A multifunction driver can enumerate a virtual device in the system for each of the streams, or channels, from a single physical device. Thus if a multifunction device supports more than one channel (e.g. a data channel, a control and status channel, a diagnostics channel, and a location based services channel (LBS) for a complex modem), then the multifunction driver can create a virtual device in the system for each of the channels of the multifunction device. In addition to this, the set of virtual devices created in the system for the device can be composed of a different set of device types (e.g. modem ports, COM ports, network adapters, etc.).
Another advantage of a multifunction driver is that it also allows for virtual devices to be dynamically loaded and unloaded in the system at any time while the driver is loaded. However, contemporary multifunction device drivers contain a static configuration that does not allow these drivers to take advantage of this feature because the configuration presented by the hardware device to specify the virtual devices to be presented in the system is static in nature. So the set of virtual devices to be presented in the system can only be done so at the time the multifunction driver is loaded for the device in the system. In order to change the set of virtual devices, the multifunction device must be re-enumerated, by either being removed from the host system or being subject to a power cycle or reset operation, with a new or alternative set of device interface configuration parameters. This is one disadvantage of the multifunction driver architecture approach.
This static nature of device configurations presented by multifunction devices 322 creates other limitations on the use of multifunction drivers 312. Channels cannot be dynamically added or removed based on run-time decisions or non-volatile memory setting in host platform or device. The virtual channels must be established at the time the device 322 is enumerated in the host system. In order to change the virtual channel/device configuration, the device must be re-enumerated, by either being removed from the host system or being subject to a power cycle or reset operation, with a new or alternative set of device interface configuration parameters. Another disadvantage is that definitions of new virtual channels and/or devices require a new device configuration rather than just a firmware, software, or non-volatile memory upgrade.
Since the method for specifying the channel and virtual devices to be established is driven by the device configuration, the host system has no opportunity to influence the set of virtual channels/devices to be supported beyond what is presented in the device configuration to the host. This can be considered as a master-slave relationship and thus is another disadvantage as it would be advantageous to allow the host system to have influence or control over the set of channels and virtual devices to be established beyond what is presented in the device configuration to the host.
One more disadvantage of the multifunction driver architecture, is that the number of virtual devices that are exposed are subject to the configuration restrictions imposed by certain bus specification associated with the device type (i.e. a USB or PCI-Express device bus specification). These configurations could have size or entry limitations that indirectly limit the number of channels or virtual devices that the device configuration can specify to the host system.
Many of the disadvantages of a multifunction driver architecture described in the previous paragraph are supported through the implementation of a virtual channel multiplexing driver architecture. FIG. 3 illustrates an example non-bus based virtual channel multiplex driver architecture. Channel multiplexing protocols allows a number of simultaneous sessions, or channels, over a single asynchronous interface. Each session/channel consists of a stream of bytes transferring various kinds of data.
A virtual channel multiplexing protocol driver 312 can allow for the negotiation of the set of virtual sessions, or channels, to be established between the host and the device 322. Thus the channel establishment is a peer-to-peer relationship rather than master-slave since both the host and the device 322 can have influence over which virtual channels are to be established. Virtual channel multiplexing protocol drivers 312 can also be dynamic in nature in that they can allow virtual channels to be established and terminated at any time. Also, adding new virtual channels do not require a new device configuration since the definition of a virtual channel is outside the scope of device configuration as long as the device configuration covers the definition of the single channel for all of the virtual channels to be multiplexed over.
Though contemporary virtual channel multiplexing protocol driver architectures provide solutions for the specified limitations and disadvantages of the multifunction driver architecture, they have their own limitations since contemporary virtual channel multiplexing driver architectures do not employ the use of a bus architecture. Since these multiplexing driver architectures are not bus based, they do not allow virtual channels to be represented by a set of different virtual devices (e.g. all virtual channels have to be a COM port vs. having a combination of COM ports, modem ports, and network adapters, etc.). Also, these virtual channel multiplexing driver architectures do not allow virtual devices to be dynamically loaded or unloaded in the system. For example, when needed, a network adapter can be loaded at run time by a bus driver that supports a multifunction device 322. However, a non-bus based virtual channel multiplexing solution does not allow the device 322 to be loaded or unloaded because it only supports one device type and only presents itself as one device to the system.
So to summarize, there exists two different driver architectures out there to address the needs of these more complex multifunction devices. Though both of these driver architecture solutions provide clear advantages to address the needs of these complex multifunction devices, they also both have significant disadvantages that restrict taking advantage of the flexibility and dynamic capability of these ever more complex devices.